home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000119_news@newsmaster….columbia.edu _Thu Oct 16 14:52:47 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id OAA28101
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 16 Oct 1997 14:52:46 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id OAA00365
  7.     for kermit.misc@watsun; Thu, 16 Oct 1997 14:52:45 -0400 (EDT)
  8. Path: news.columbia.edu!panix!news.eecs.umich.edu!nntprelay.mathworks.com!newsgate.duke.edu!news.eng.convex.com!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Kermit via PPP under DOS?
  12. Message-ID: <$QmoOmiES1Xq@cc.usu.edu>
  13. Date: 16 Oct 97 09:59:26 MDT
  14. References: <k1c7kBQEU5Wv@cc.usu.edu> <omn2kcqegc.fsf@tees.cs.ualberta.ca>
  15. Organization: Utah State University
  16. Lines: 58
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:7898
  18.  
  19. In article <omn2kcqegc.fsf@tees.cs.ualberta.ca>, Vladimir Alexiev <vladimir@cs.ualberta.ca> writes:
  20. > In article <5jzp7SiZjuUm@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
  21. > 
  22. >> >> >> > Is BOOTP impossible with a SLIP interface? How about DHCP?
  23. >> BOOTP and DHCP require a local MAC address to work with, SLIP has no MAC
  24. >> address
  25. > Ok, now: Is BOOTP availability over PPP links sufficient incentive  to warrant
  26. > pursuing this issue? 
  27. > 
  28. >> continue the conversation with the authors of those drivers and see if they
  29. >> will reveal the extent to which they perform the required emulation.
  30. > Ok, I'll try that.
  31. > 
  32. >>     Proxy ARP et al have not the slightest to do with Kermit (or other
  33. >> client) internals. That is outside of and unknowable to these clients.
  34. > I know that. I was trying to figure out how does class 1 emulation work.
  35. > 
  36. > For a PPP link, Kermit`s job is pretty simple: it has to send all it wants to
  37. > send down the link, without caring mcuh about MAC addresses. That's why I
  38. > think it would be an easy fix: Kermit could simply disregard some of its
  39. > "doubts" about the faithfulness of the class 1 emulation and just go ahead.
  40.  
  41.     You are still grasping the problem by the wrong end. "Just disregard"
  42. may seem to be convenient for your situation but is plain wrong in general.
  43. The problem is very likely improper emulation of Ethernet by the PPP drivers,
  44. as I have speculated each time this thread has a new message.
  45.  
  46. >> MSK will report 
  47. >> 1. if it is unable to register with the Packet Driver for IP and ARP packets
  48. >> 2. if another station responds to an ARP for MSK's own IP address,
  49. >> 3. and if it is unable to receive a response to an ARP.
  50. > This is the kind of info I need to figure it out (if at all possible from
  51. > external observation only). Does the message "Unable to ARP resolve" mean item
  52. > 3 above? Will these conditions appear in the order listed, so can I assume
  53. > that 1 and 2 do not happen?
  54.  
  55.     Unable to ARP resolve means just what it says: ARP request sent, no
  56. matching ARP reply received. Malformed ARP replies are the same as no reply.
  57.  
  58. >> If those conditions are met and the driver proclaims to be Ethernet then the
  59. >> driver had better behave like Ethernet...  Kermit does tell you if
  60. >> interfacing conditions fail 
  61. > What other errors can happen from that point on? (Ok, perhaps this is a stupid
  62. > question :-) Can you think of other interfacing conditions that can fail,
  63. > apart from the listed 3? 
  64.  
  65.     I say again, the emulation is likely broken. Understanding the overall
  66. situation does require some knowledge of TCP/IP on Ethernet, and this is not
  67. the place to provide a course on that. The authors of those PPP drivers are
  68. the ones to take on the task, as has been nicely demonstrated today.
  69.     Joe D.
  70.  
  71. >> it cannot tell anyone about Ethernet simulation failures in an external
  72. >> driver.
  73. > I was hoping that we can figure out what more does Kermit expect from a class
  74. > 1 emulator compared to other TCP apps (and you're starting this, with the 3
  75. > conditions above). Now I'll try from the other end, ask emulator authors what
  76. > less do these emulators provide compared to true ethernet drivers.